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1. Related to Reading/Querying Multiple Authority Systems 


ID: 

UC1.1— Saskia Woutersen (U. Amsterdam) 

Title: 

Researcher submits document to institutional repository 

Description: 

Researcher registers his publication in the IR and identifies his/ her co-authors. 

Primary Actor: 

Researcher 

Preconditions: 

Researcher is logged into system, and can (while registering his/ her publications) identify 
his/her co-authors easily. This can be done by providing a list of suggested co-authors that are 
already identified. 

Postconditions: 

Researcher is allowed to register in the IR 

IVhin 

Success Scenario: 

1. Researcher logs in 

2. IDs of the researcher are automatically shown 

3. Researcher enters the name of the co-author 

4. The IR shows a list of names available with an ID 

5. Researcher selects the correct name(s) and identifier(s) 

6. Researcher saves the data. 

7. System registers the names and identifiers in confirmation message. 

Extensions: 

1. To make it easy, provide a list of co-authors of the author that are already in the system. 

2. What to do when the name is not available or the name has no ID? Can a researcher create 
a new one for another author? 


ID: 

UC 1.2— Wolfram Horstmann (U. Oxford) 

Title: 

Researcher searches for colleague's publications across repositories to track a given 
discipline 

Description: 

A researcher would like to retrieve all full-texts published by a colleague on climate change. 
The researcher has moved between institutions and has changed her name twice since 
starting her work. 

Primary Actor: 

Researcher 

Preconditions: 

• The researcher has submitted her papers to institutions' repositories 

• There is a cross repository search service such as GoogleScholar or BASE-search. NET 

• Each repository exposes an author identifier for the researcher 

• The search service can access the repositories' author identifiers 

• There is a disambiguation service in case different author identifiers are used 

• The disambiguation service has the information that different names and records belong 
to the same person ("same-as") 

• The search service is able to use the disambiguation service and aggregate 

• The researcher is able to use the search service to search the colleague's name 

Postconditions: 

• The researcher is able to understand that all publications belong to the same person even 
if there are different names 

IVhin 

Success Scenario: 

1. Researcher retrieves a result list with all publications of the same colleague who had 
published under different names and in different repositories 


3 


Registering Researchers in Authority Files: Use Cases 


#oclcresearch ftrafreport 


Extensions: 

la. Search service warns that the researcher has changed names and several separate 
searches might be required 

lb. Search service warns that the researcher has changed institutions and several separate 
searches might be required 


ID: 

UC1. 3— Joanne Dunham (U. Leicester) 

Title: 

Funder wishes to track funded research outputs 

Description: 

Funder would like to retrieve all the publications by researchers (authors and co-authors) 
associated with a specific grant or 

Funder requests that a Researcher reports all their research outputs associated with a 
specific grant. 

Primary Actor: 

Funder/ Researcher 

Preconditions: 

The Researcher has submitted all their research outputs in the way specified by the grant 
funding body i.e. open access if applicable, Institutional Repositories, citation/ bibliographic 
databases etc. 

The publications can be identified as relating to a specific grant. 

The funder/ researcher is able to search using the researcher's name and/ or an author 
identifier is available for each researcher (both for lead researcher and co-researchers). 
Cross database searching is available. 

OR 

Researcher has recorded (or all relevant research outputs have been associated with the 
researcher on their researcher profile) all his or her research outputs associated with a 
specific grant on a research information management system (e.g. Symplectic). 

Postconditions: 

Funder/ Researcher can search for and retrieve all research outputs associated with a 
specific grant 

IVhin 

Success Scenario: 

1. Can log into a research information management system/ database(s) 

2. Can search by Researcher name(s)/identifier(s) 

3. Can search by Grant identifier 

4. Can select the data 

5. Can save and output the data in different formats 

Extensions: 

CrossRef has announced FundRef, a pilot collaboration between scholarly publishers and 
funding agencies that will standardize the names of research funders and add grant numbers 
attributed in journal articles or other scholarly documents. The collaboration would allow 
researchers, publishers, and funding agencies to track the published research that results 
from specific funding bodies. See: httn:// www.crossref.ora/01comnanv/ Dr/ news050212.html 


ID: 

UC1.4— Ana Cristan (Library of Congress) and Melanie Wacker (Columbia University) 

Title: 

Cataloger wishes to reuse data from other researcher registries or Name Authority Files 

Description: 

Cataloger working in the library, searches for the author/ contributor in the Name Authority 
Frle (NAF) as well as other sources and is able to reuse a record created for an institutional 
repository when a new name authority record is needed. 

Primary Actor: 

Cataloger 

Preconditions: 

Various name authority files and researcher registries are linked in one system, such as the 
Virtual International Authority Frle (VIAF). 

That system, e.g. VIAF, can be queried through the bibliographic utility used for name 
authority record creation (e.g. OCLC). 

There is a mechanism for catalogers to use an existing record as a template to start building 
the name authority record. 
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Postconditions: 

The creation of a new name authority record has been accomplished in a shorter amount of 
time. 

IVhin 

Success Scenario: 

1. Cataloger accesses the cataloging utility used to search and create name authority records 
for the NAF. 

2. Cataloger searches the NAF and does not find a match. 

3. Cataloger queries other researcher registries or name authority files without having to 
leave the bibliographic utility. 

4. Cataloger finds a match. 

5. Cataloger is able to either reuse the existing record to build the name authority record or 
to pull in needed elements. 

Extensions: 

2. If the cataloger does find a match use case 2.4 may apply. 

5. This may only apply to certain elements that are consistent in most registries/ authority 
files. 


ID: 

UC1. 5— Philip Schreur (Stanford University) 

Title: 

University administrator wants to collate the intellectual output of the researchers at his 
or her institution 

Description: 

University administrator wants both to assess the intellectual impact of a particular subset of 
the university's researchers and determine their areas of strength (and weakness) by a review 
of the researchers' intellectual output. 

Primary Actor: 

University Administrator 

Preconditions: 

Nfetadata for all of a researcher's intellectual output are available. 

The metadata is robust enough to allow for various types of sorting. 

The metadata has been created in a consistent way to allow for successful integration. 

A researcher has a single identity or has successfully linked multiple identities to allow for 
collation of intellectual output. 

There is a single database that contains all the metadata for all intellectual output or 
multiple databases that can be searched simultaneously and the results deduped. 

A similar database is available at all institutions against which a comparison is to be made. 

Postconditions: 

A University Administrator can create a file of all the intellectual output of a particular 
researcher or the intellectual output of a department by a particular subject across 
researchers. 

Nfein 

Success Scenario: 

1. University Administrator accesses a single database containing the intellectual output of 
their institution. 

2. University Administrator queries the database for the intellectual output of individual 
researchers. 

3. University Administrator sorts the results of the queries and groups subsets of researchers 
as needed. 

4. University Administrator analyzes the results in regards to subject strengths. 

5. University Administrator compares the results to the research output of other institutions. 
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ID: 

UC1. 6— Philip Schreur (Stanford University) 

Title: 

Researcher wishes to find other researchers working in the same field 

Description: 

A researcher wishes to find collaborators for a new project either within or outside their 
institution by querying a database(s) of the intellectual output of others in their field. 

Primary Actor: 

Researcher 

Preconditions: 

Nfetadata for all of a researcher's intellectual output are available. 

The metadata is robust enough to allow for various types of sorting. 

The metadata has been created in a consistent way to allow for successful integration with 
other researcher's output. 

A researcher has a single identity or has successfully linked multiple identities to allow for 
collation of intellectual output. 

There is a single database that contains all the metadata for all intellectual output or 
multiple databases that can be searched simultaneously. 

A similar database(s) is available at all institutions from which potential collaborators are 
sought. 

Postconditions: 

The ability to create a list of potential collaborators both within and across institutions. 

Nfein 

Success Scenario: 

1. Researcher defines a new proj ect. 

2. Researcher seeks successful collaborators within the same field of interest. 

3. Researcher queries a database(s) containing potential collaborators and sorts the results by 
subject. 

4. Researcher evaluates the intellectual output of potential collaborators. 

5. Researcher contacts potential collaborators for interest. 


ID: 

UC1. 7— Philip Schreur (Stanford University) 

Title: 

Researcher wants to explore the background of current collaborators 

Description: 

Researcher wishes to explore the intellectual output of current collaborators on a project. 

Primary Actor: 

Researcher 

Preconditions: 

Nfetadata for all of a researcher's intellectual output are available. 

The metadata is robust enough to allow for various types of sorting. 

The metadata has been created in a consistent way to allow for successful integration. 

A researcher has a single identity or has successfully linked multiple identities to allow for 
collation of intellectual output. 

There is a single database that contains all the metadata for all intellectual output or 
multiple databases that can be searched simultaneously. 

A similar database is available at all institutions from which current collaborators have come. 

Postconditions: 

A researcher is able to search a database containing the entire intellectual output of a 
collaborator with whom they are currently working. 

Nfein 

Success Scenario: 

1. Researcher identifies another researcher with whom they are currently working. 

2. Researcher queries a database(s) containing their entire intellectual output. 

3. Researcher receives a single result of all of the other researcher's intellectual output. 

4. Researcher manipulates the result by various aspects of interest. 
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2. Related to Creating/ Updating Multiple Authority Systems 


ID: 

UC2.1— Laura Smart (California Institute of Technology) 

Title: 

Staff member wants to batch search and update multiple ID systems 

Description: 

A staff member of a university wishes to determine if faculty members currently have an ID in 
relevant systems and, if not, register them 

Primary Actor: 

Staff member 

Preconditions: 

Staff member has list of researcher names in a standard format 
There is a directory of identifier services and staff member has access to it 
There is a standard mechanism for searching and updating identifier services 
Identifier services allow proxies to create provisional records 

Postconditions: 

All faculty on list have ID in relevant systems 

IVhin 

Success Scenario: 

1. Staff member selects multiple authority systems to search 

2. Staff member is prompted to add "search list" of names to the query engine 

3. Staff member reviews search "result set" and removes false matches to create a 
"normalized set" of results 

4. Staff member compares normalized results set with initial search list to determine which 
faculty names aren't yet represented in an ID system. 

5. Staff member removes matches to create a new "working list" 

6. Staff member uploads "working list" to ID system to create new records 

Extensions: 

2. Institutional/ Organizational search could be used to find all personal names in a ID system 
affiliated with a given university. 

4. Comparison could be done manually and locally in spreadsheets. 

5. Assumes there is one system which could propagate names to other systems. Staff member 
may need to upload list to individual systems. 


ID: 

UC2. 2— Amanda Hill (University of Manchester) 

Title: 

Researcher wants to correct an error 

Description: 

A researcher views the information about herself in the authority system and notices an error. 
She is able to report the error or edit the record herself in order to correct it. 

Primary Actor: 

Researcher 

Preconditions: 

There is a publicly-accessible web interface to information about researchers 
There is a mechanism for individual researchers to update information in the system 

Postconditions: 

The information has been corrected. 

IVhin 

Success Scenario: 

1. Researcher accesses the authority system. 

2. Researcher views information associated with her identity and realizes that there is an 
error. 

3. Researcher interacts with the system to update the information. 

4. Updated information is displayed in the system. 

Extensions: 

1. This may involve the researcher registering a user account with the system, requiring 
authentication of some sort. 

3. The system could otherwise provide a contact form for manual update of the information 
by administrators. 

4. The updated information may need to be propagated out to other systems 
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ID: 

UC2.3— Laura Smart (California Institute of Technology) 

Title: 

Researcher wants to register in multiple systems 

Description: 

A researcher wants to register a persistent identifier in all relevant systems. 

Primary Actor: 

Researcher 

Preconditions: 

There is a publicly-accessible web interface to information about researchers. 

There is a mechanism for individual researchers to update information in the system. 

Postconditions: 

Researcher has persistent identifiers in every system desired. 

Nfein 

Success Scenario: 

1. Researcher accesses web site of researcher information. 

2. Researcher searches for her own name/ identifier and doesnt find any results. 

3. Researcher adds her information to the system. 

4. Researcher is prompted to select desired ID systems for adding name information. 

Extensions: 

2. Researcher may find that some ID systems have harvested name information and already 
have records for her - some of which may be correct and some may need revisions. 

3. Researcher may need to correct information in multiple systems, necessitating individual 
account creation, login, editing sessions, etc. 


ID: 

UC2. 4— Amanda Hill (University of Manchester) 

Title: 

Cataloger wants to add IDs to catalog record 

Description: 

A cataloger in an institution wants to add identifiers for individuals to a catalog record 

Primary Actor: 

Cataloger 

Preconditions: 

There metadata schema used includes an element that allows the cataloger to record an 
external identifier. 

There is sufficient information by which the cataloger can reliably identify an individual. 
There is an identifier associated with an individual which resolves to information identifying 
that person uniquely. 

That identifier can be freely used in other systems. 

Postconditions: 

The cataloger has added identifiers for individuals to their catalog records. 

Nfein 

Success Scenario: 

1. Cataloger accesses the authority system. 

2. Cataloger searches for names of individuals and makes a positive identification. 

3. Cataloger populates a field in the catalog record with the external identifier from the 
authority system. 

4. Catalog record displays a link to the authority system's record for the individual. 

Extensions: 

2a. The cataloger does not find a record in the system for an individual. 

2al. The cataloger has the opportunity of creating a new record/ requesting creation of a 
new record 


ID: 

2.5— Micah Altman (Massachusetts Institute of Technology) 

Title: 

Systems act to maintain consistency of information over time 

Description: 

See the Researcher ID Information Flow diagram. As per use cases 2. 1-2.4 and 4. 1-4.3 
identifiers may be deleted, merged, and added over time, and information linked provided by 
identifier authorities such as author profile information related to an identifier or outputs 
contributed to by that author may also be updated. Systems need to act so that the 
information delivered in profiles is constituent (eventually, not immediately) with the 
information provided by the authoritative systems. 
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Primary Actor: 

Internal catalog and profile systems. 

Preconditions: 

Some change occurs in aggregator record: (a) add/ delete/ merge identifier OR (b) add/ change 
associated author information (e.g. affiliated institution) OR(c) add/ change to maintained 
profile information (e.g. publication list) 

Postconditions: 

Information displayed in gateway is identical to that in affiliated aggregator record 

IVhin 

Success Scenario: 

1. A scheduling service (e. g. cron) initiates an update process for the { Library Catalog, 
Institutional Repository, and Institutionally Deployed Profile } internal aggregator systems 

2. Generate list of ID's by Aggregator existing in Internal aggregator system 

3. Query Aggregator on list of ID' s from that Aggregator source 

4. For each ID registered in the internal system: 

a. Check whether ID has been deleted in Aggregator -> delete in Internal aggregator 

b. Determine whether ID has been merged -> merge in internal aggregator system 

c. Determine whether information related to author has been updated -> update 
profile information in database system 

5. Generate updated list of ID's per Aggregator 

a. Query each Aggregator (not just Aggregator responsible for minting ID) for any 
updated outputs (publication) information associated with each id -> add to internal 
aggregator 

6. Generate list of names in Internal aggregator System that do not have ID's yet associated 

a. Query each aggregator for ID's that (i) have been created since the last query time ; 
(ii) match the name/ institutional information associated with the unidentified 
researcher 

b. If there are any matches, record potential matches across all aggregators: generate 
report of potential matches: route for manual review and approval. 

Extensions: 

Alternative to 1-3 is that Aggregator provides notification service 

1. Register list of 'watched' ID's with Aggregator 

2. When information related to ID changes, Aggregator registers notification with 
Internal system 

3. Internal system queries information for that Aggregator 

Alternative to 6 is to register interest in new ID's associated with an institution or query 
string. (E.g. notify when a researcher registers whose institution matches "MT") 

6. Register list of queries with Aggregator 

7. When query results change, Aggregator sends a list of new results to Internal System. 


3. Related to Administering Multiple Systems 


ID: 

UC 3. 1— Daniel Hook (Symplectic) 

Title: 

Aggregator wants to offer a pool of researchers with their persistent identifiers as 
a service 

Description: 

Content aggregators of some type of research data, which may include research outputs such 
as publications or data sets, wish to offer a pool of researchers with persistent IDs either 
globally or within an institutional context. 

Primary Actor: 

Researcher as an agent wishing to gain data so that he or she can perform some level of data 
analysis. 

Preconditions: 

Aggregators work in a global context (e.g., Thomson Reuters, Elsevier, MH, NSF) or 
represent a research information management system such as Atira/ Elsevier Pure, Alvedas, 
Converts, Symplectic. 

Postconditions: 

Researcher retrieves persistent IDs for the person(s) queried. 


9 


Registering Researchers in Authority Files: Use Cases 


#oclcresearch ftrafreport 


IVhin 

Success Scenario: 

1. Researcher wishes to understand something relating to unique people either associated 
with their institution or more generally. Typically, this might include promotion 
procedures, hiring/ tenure procedures, faculty searches and accurate institutional 
benchmarking. 

2. Researcher browses aggregator database by topic and finds an author name. 

3. Researcher wishes to find all works by author but needs to be sure that they are correctly 
disambiguated. 

4. Researcher locates unique identifier associated with author. 

5. Researcher searches database using author unique identifier. 

6. Researcher downloads metadata associated with author' s unique identifier. 

7. (Optional) Researcher looks at co-author lists on metadata and repeats procedure above to 
understand co-authorship network / benchmarking statistics / size of field etc. 


ID: 

UC 3.2— Daniel Hook (Symplectic) and Michael Conlon (University of Florida) 

Title: 

Identity management system automatically disambiguates people and disseminates IDs 

Description: 

Two or more Identify management systems "talk" with each other for the purpose of 
disambiguating or improving the data they hold. 

Primary Actors: 

Originator system: a system such as VIVO or ORCID that is attempting to add relevant 
metadata to its store or disambiguate data that it holds. 

Recipient system: another system such as VIVO or ORCID that may hold data about the 
individual being queried by the Originator system. 

IVfetadata being transmitted about an individual may include: first name, last name, email 
address, keywords related to their research, role, name of organizational affiliations known 
about, articles published (DOIs?), journals in which publications have appeared, grants held. 

Preconditions: 

Recipient system has sufficient data to respond to the query from the originator system. 

Postconditions: 

Originator system retrieves a persistent ID or other key information from recipient system or 
recipient system can suggest disambiguation of entities. 

Nfein 

Success Scenario: 

Find ORCID or other key information from ORCID system 

1. <Originator system> supplies metadata describing an individual to the cecipient 
system>. 

2. Recipient system> compares the received metadata with metadata in its store and 
returns a set of metadata bundles describing individuals who appear to match the 
searched metadata together with confidence levels qualifying the strength of the match. 

3. <Originator system> compares each returned metadata set with what is known about the 
queried set to see if it can corroborate the match based on the wider data provided (i.e. 
inference through shared co-authors or co-grant holders). 

4. <Originator system> asserts association with ORCID from <Recipient system> if 
confidence threshold is exceeded. 

Recipient system suggests disambiguation of entities 

1. Originator system> supplies sets of metadata describing records that appear to describe 
the same individual to the cecipient system>. 

2. <Recipient system> compares the received metadata with metadata in its store and 
returns a set of metadata bundles describing individuals who appear to be the same as 
those in the dataset provided together with enhancements in "peripheral" metadata 
(i.e. publications, co-authors etc), confidence in matching to the entities provided and 
likely disambiguation (or clustering) of the entities together with confidence levels 
concerning the clusters. 

3. Originator system> takes clusters returned along with supplementary metadata and 
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calculates confidence levels of clusters based on its own inference taking supplementary 
metadata and confidence levels of external system into account. 

4. <Originator system> stores same as assertions with provenance attributed to <Recipient 
system>and time stamped to the request date (so that if the results of a negotiation in 
the future change, it is understood that metadata may have changed in the <Recipient 
systems*. 


ID: 

UC3.3— Saskia Woutersen (U. Amsterdam) 

Title: 

Researcher needs to register co-authors 

Description: 

Register co-authors. 

Primary Actor: 

Researcher 

Preconditions: 

Researcher is logged into system (not only IR as is Use Case 1. 1), and can (while registering 
his/ her publications, projects, etc) identify his/her co-researchers easily. This can be done 
by providing a list of suggested co-authors that are already identified. 

Postconditions: 

Researcher is allowed to register in the system 

IVhin 

Success Scenario: 

1. Researcher logs in 

2. IDs of the researcher are automatically shown 

3. Researcher enters the name of the co-author 

4. the system shows a list of names available with an ID 

5. Researcher selects the correct name(s) and identifier(s) 

6. Researcher saves the data. 

7. System registers the names and identifiers in confirmation message. 

Extensions: 

1. To make it easy provide a list of co-authors of the author that are already in the system. 

2. What to do when the name is not available or the name has no ID? Can a researcher create 
a new one for another author? 


4. Related to Updating within Single Authority System 


ID: 

UC 4. 1— Andrew MacEwan (British Library) 

Title: 

Researcher or librarian discovers duplicate identifiers in same system, wishes to merge 
them. 

Description: 

A researcher or librarian views the information about herself in the authority system and 
discovers that two separate IDs have been assigned to her, associated with different works. 
She is able to report the error or edit the records herself in order to merge the data, 
maintain one ID and deprecate the other. 

Primary Actor: 

Researcher or librarian 

Preconditions: 

There is a publicly-accessible web interface to the authority system 
There is a mechanism for individual researchers to update information in the system 
The authority system controls diffusion of the identifier into other databases and has a 
notification protocol to remove and replace a deprecated ID 

Postconditions: 

The information has been corrected and one ID has been removed from the system 

Nfein 

Success Scenario: 

1. Researcher/ librarian accesses the authority system 

2. Researcher/ librarian views information associated with her identity and realizes that 
there are two IDs that require merging 

3. Researcher/ librarian interacts with the system to update the information and indicates 
preference for which ID should be kept and which deprecated 

4. The separate records are merged and one of the IDs is deprecated. 

5. Notifications are sent to all other databases to which the deprecated ID has been sent 
replacing with the correct ID 

Extensions: 

3a. This may involve the researcher/ librarian registering a user account with the system, 
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requiring authentication of some sort 

3b. The system could otherwise provide a contact form for manual update of the information 
by administrators (Note: this is the method provided for the ISNI system) 

4. The updated information may need to be propagated out to other systems (Note: methods 
above derived from ISM update protocols) 


ID: 

UC 4.2— Andrew MacEwan (British Library) 

Title: 

Researcher or librarian discovers two individuals represented by the same ID, wishes to 
split them 

Description: 

A researcher or librarian views the information about herself in the authority system and 
discovers that works or other data associated with another identity with the same name have 
been assigned to her ID. She is able to report the error or edit the records herself in order to 
remove the data not associated with herself and use it to create another record for the other 
ID with its associated metadata 

Primary Actor: 

Researcher or librarian 

Preconditions: 

There is a publicly-accessible web interface to the authority system 
There is a mechanism for individual researchers to update information in the system 
The authority system controls diffusion of the identifier into other databases and has a 
notification protocol to remove and replace a deprecated ID 

The authority system holds metadata showing the database source of each metadata element 
it holds in a given record 

Postconditions: 

The information has been corrected and another ID has been added to the system 

Nfain 

Success Scenario: 

1. Researcher/ librarian accesses the authority system 

2. Researcher/ librarian views information associated with her identity and realizes that 
there is false information about works, affiliations that belong to another identity 
with the same name included in her ID record. 

3. Researcher/ librarian interacts with the system to update the information and 
indicates which data should be removed from her ID 

4. The original record is corrected and the data removed is used to create a new recrd 
for another ID. 

5. Notifications are sent to all other databases which are the source of the false 
metadata associated with the ID informing them of the data to be split from their 
existing ID and providing the new ID that can be associated with that data. 

Extensions: 

3a. This may involve the researcher/ librarian registering a user account with the system, 
requiring authentication of some sort 

3b. The system could otherwise provide a contact form for manual update of the information 
by administrators (Note: this is the method provided for the ISM system) 

4. The updated information may need to be propagated out to other systems (Note: methods 
above derived from ISM update protocols) 


ID: 

UC 4.3— Daniel Hook (Symplectic) and Michael Conlon (University of Florida) 

Title: 

Researcher discovers metadata that needs amendment in single authority system 

Description: 

A researcher views the information about herself in an authority system and discovers errors 
that need correction. 

Primary Actors: 

Database owner: the owner of the authority system and the curation process associated with 
the presentation of the data, e.g. Cornell (arXiv.org), Elsevier (Scopus), Thomson Reuters 
(Web of Science) 

Data owner: the primary publisher of the data— this may be the copyright holder but may not 
always be (open access), e.g. Elsevier, Macmillan etc. 

Licensed Subscriber: a person or service wanting to understand when data has changed in the 
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Database, e.g. Symplectic Elements; VIVO; Individual researcher wanting to track the research 
of others in their field; Government agent wishing to track research for assessment purposes. 
Data creator: a researcher or institution that created the research output (effectively the 
named author), e.g. Albert Einstein, The CERN Collaboration (or member thereof). 

Preconditions: 

A "single authority system" or data source that can be considered authoritative, such as ArXiv, 
PubNfed, Scopus, Web of Science. Some data sources such asArXiv.org are in the direct control 
of the researcher and hence the actor mapping is more involuted. 

Postcondition: 

The information has been corrected and broadcast. 

Nfein 

Success Scenario: 

1. <Data creator> browses online authority source owned by “Database owner>for their 
own outputs OR “licensed Subscriber receives / browses online authority source 
owned by “Database owner for outputs they are monitoring for some activity. 

2. “Data creator spots a data error in one or more of their own research ouputs OR 
■licensed Subscriber spots a data error in one or more of the outputs in which they 
have an interest. 

3. “Data creator reports the error to the “Database owner OR “licensed Subscriber 
reports the error to the “Database owner. 

4. “Database owner corroborates nature of error via third party. (In the case of 
Thomson Reuters or Scopus this is likely to be a manual/ visual check of the paper 
publication or contacting the “Data owner. In the case of arXiv. org this may involve 
contacting the “Data creator.) 

5. “Database owner changes the metadata to reflect changes (or in the case of 
arXiv.org, asks the “Data creator to make the changes). “Database owner notifies 
“Data creator^/ “licensed Subscriber of change in metadata OR “Database owner 
reports that the “Data creator or “licensed Subscriber that the report is in error 
and that metadata will not be changed. 

6. 6. “Database owner broadcasts changes to “licensed Subscribers^ 
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